\title{Database Design}
\author{Joseph Barratt}
\date{\today}

\documentclass[12pt]{article}
\usepackage{fullpage}
\usepackage{setspace}
\usepackage{hanging}

\begin{document}
\maketitle

\doublespacing

Over the years, computer scientists have considered many approaches to database
design. The top three contenders in the 1970s were the hierarchal model, the
network model, and the relational model. IBM heavily promoted relational
%discuss other models?
databases, and by the 80s, the relational paradigm dominated the industry
(cbsolution). Relational databases organize information into tables, where each
record is a row and its attributes are stored in columns. Developers use many
complicated techniques for modeling complex data relationships involving
multiple, related tables. Information is retrieved from the database and
manipulated using a query language called SQL. Using SQL, one can easily
construct a great number of tables to model everything from bank accounts to
sandwich orders. The network and hierarchal models faded away, and relational
databases went uncontended. 

Today, much of the debate centers around the issue of the classical relational
database vs. the trendy new document-based database. The document-based database
has many names: internet-facing, attribute-oriented, distributed database,
sharded sorted array, distributed hash table, and key/value store. In short, a
document-based database stores data in documents rather than tables. Documents
are collections of named attributes mapped to values, and a database consists of
a collection of documents. Web services have recently turned to document-based
databases to solve the particular problems facing web scale applications.
Challenging the long-standing and undisputed reign of relational database
models, proponents of the document-oriented paradigm claim that relational
databases no longer meet the needs of the modern web-scale application.

Still, relational databases have seen widespread use and popularity, and that's
not for no reason. Relational databases provide a well-balanced mix of
simplicity, robustness, flexibility, performance, scalability, and compatibility
(Bain 2). Additionally, whether for the best or not, relational databases won
the competition for standard model decades ago, which means that relational
databases now have thirty plus years of experience, development, and support
behind them. As the technology developed, so did the field, and there is a ripe
selection of experts in database design who know relational databases inside
out, and have accumulated the experience to make them do any necessary tasks,
even if inelegantly. Meanwhile, relational databases run on database engines
which have gotten faster and more reliable, as they've been actively developed
for decades.  Finally, any development tools that has something to do with
databases probably have special support for relational databases and SQL.

When the relational database rose to prominence in the 1970s, the application
landscape differed starkly from today's situation. Relational databases are
scalable, but they only scale up. This means that if a company has a data center
and requires a greater capacity, they can increase the size of that data center
by buying more expensive machines with more memory. They can't easily scale
sideways, which would mean building another data center to share the load with
the first. Web services generally have many data centers since they serve a wide
geographic area. These data centers must share information and stay
synchronized. If more data centers are built, information must be migrated
around as needed. Web scale means sideways, distributed scaling. Another problem
web services pose is that they must be easily developed, on demand.  Offline
applications are developed and then shipped, but web applications are
continuously developed and constantly shipped. This summer I worked at a web
service company and we deployed a brand new version of the site every week.
Change like that requires flexibility everywhere, and relational databases don't
naturally have that kind of flexibility. Often, tables are added on an as-needed
basis until the database is a spaghetti of confusing information structures.

Addressing some of these issues, document-based databases have received a lot of
attention in recent years. Document-based databases scale sideways by original
design. Their design is generally simpler than a relational model, and this
lends to their scalability and also their flexibility. New attributes can be
added to a document with little fuss, and need not be synchronized across data
centers. In fact, application code essentially just uses an attribute it needs
as if it's there, and the database adds that attribute. The schema is a product
of the code, and better mirrors the object-oriented program design which
dominates the field today. This means that the database is more intuitive to the
programmers, as information doesn't have to be put together with complicated
join statements. Additionally, since document-based databases are more
object-like in nature, integrating database calls into an application is much
less work, and much less error-prone.

One might wonder whether ``intuitive'' representation is a truly scientific
concern. But it's actually a huge part of computer science. In fact, computer
science is all about the way that humans can reason about computation. If we
wanted, we could do away with all abstraction and always lay out code in binary.
We could achieve much greater efficiency in product that way, but not in
process. The difficulty of reasoning about computation without levels of
abstraction leads to inflexible, painstaking and ultimately buggy code.
Relational databases rose to prominence in part because at the time the language
of choice for the applications that would be using it was COBOL, which lends
itself to tabular representations of data. This how people reasoned about
computation at the time, so it made sense to use a database model that was
compatible with it. Prominent computer scientist Edsger Dijsktra thought that
``the use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offence'' (Dijsktra). As computer science has developed,
the way we reason about computation has developed into more flexible,
expressive, and intuitive models. No one is starting a new project in COBOL
these days, yet we are still stuck with the database model it inspired.

There is an unfortunate tendency for technologies to get stuck. Things like
backwards compatibility, costly migration, and infrastructure make it hard for
new technologies to proliferate. As mentioned earlier, one of the main
advantages of the relational database model is simply that it's been around for
a long time. Additionally, it's hard to move out of it. On the other hand,
since the tools and software that implement these databases are largely
community-developed and open-source, it's not costly to acquire a new framework.
Open-source software keeps its code publicly visible so that any motivated
developer can contribute to the project. Companies open-source their database
related code because so many people are doing the same sort of work, and making
the design public allows everyone to get free development. If a company were to
keep the work it did on some framework secret, then they risk falling behind as
the open-sourced version diverged from their design. This has the nice property
that functionality really does rule the day as far as choosing a tool goes---the
software is developed on an as-needed basis and shared freely to stimulate
progress. While deploying a new tool may be costly and time-consuming, acquiring
one is not.

%With the advent of widespread cloud-services like gmail, facebook, google docs,
%and countless others, scalability is becoming an increasingly critical concern.

As for me, I believe that document-based vs. relational is not the right
question---the right question is when to use one or the other. The
document-based technologies have a long way to go to catch up with relational
systems, in terms of experience, support, and complementary technologies. People
arguing on tech forums need to take a step back and consider the needs of their
particular project. It's unfortunate that emotional bonds form between people
and the technologies they are accustomed to using. With clear eyes, the future
landscape ought to exhibit development in multiple models, maturing in their own
niches.

\newpage

\begin{hangparas}{.25in}{1}
``Databases: Relational vs Object vs Graph vs Document.'' Component Based
Solutions. Web. 08 Nov. 2011.
$<$http://www.cbsolution.net/ontarget/databases\_relational\_vs\_object\_vs$>$.

Dijkstra, Edsger. ``E.W. Dijkstra Archive: How Do We Tell Truths That Might Hurt? (EWD498).''
Computer Science Department | The University of Texas at Austin. Web. 08 Nov.
2011. $<$http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD498.html$>$.

Bain, Tony. ``Is the Relational Database Doomed?'' ReadWriteWeb - Web Apps, Web
Technology Trends, Social Networking and Social Media. 12 Feb. 2009. Web. 08
Nov. 2011.
$<$http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php$>$.

%Salingaros, Nikos A. "Life and the Geometry of the Environment." The Athens
%Dialogues E-Journal (2010). Web. 12 Sep. 2011.

%Salingaros, Nkios A. "Nikos A. Salingaros." \textit{Math.utsa.edu}. University of Texas
%in San Antonio. Web. 14 Sep. 2011.

\end{hangparas}

\end{document}
